A bug has been found in the HTTP header name length encoding in the HTX representation of haproxy, by which the most significant bit of the name's length can slip into the value's least significant bit. A remote attacker could craft a valid request that could inject a dummy content-length on input that would be produced on output in addition to the other one, resulting in the possibility of a blind request smuggling attack ("blind" because the response never gets back to the attacker).
Vulmon
A bug has been found in the HTTP header name length encoding in the HTX representation of haproxy, by which the most significant bit of the name's length can slip into the value's least significant bit. A remote attacker could craft a valid request that could inject a dummy content-length on input that would be produced on output in addition to the other one, resulting in the possibility of a blind request smuggling attack ("blind" because the response never gets back to the attacker).
https://www.mail-archive.com/haproxy@formilux.org/msg41114.html
A possible workaround for those who cannot upgrade is to block requests
and responses featuring more than one content-length header after the
overflow occured; these ones are always invalid because they're always
resolved during the parsing phase, hence this condition never reaches
the HTTP layer:
http-request deny if { req.hdr_cnt(content-length) gt 1 }
http-response deny if { res.hdr_cnt(content-length) gt 1 }